- 综合排序
- 最热优先
- 最新优先
Agent 系列（三）：Harness Engineering
2026 年 2 月，OpenAI 连续发布关于 Codex 的几篇技术文章，明确把 “harness” 放到了 Agent 工程的中心位置：他们关注的重点，已经不只是模型怎么写代码，而是如何围绕 Agent 他提到： Agent 在实际任务中总会反复犯同一类错误，于是建议 “每当 Agent 犯错，就花时间工程化一个机制，确保它永远不再犯同样错误“ 这就是 “Engineer the harness” 的核心想法 二、Harness Engineering 到底是什么 通俗来说，Harness Engineering 就是围绕 AI Agent 搭建一整套 “可执行、可验证、可约束、可迭代” 的外层运行系统。 这里的 “Harness” 可以理解为驾驭/缰绳，它不是一段 Prompt，也不是单个工作流，而是给 Agent 量身定制的 “工作轨道”： • 模型负责思考和决策； • Harness 负责把思考变成稳定执行 `Agent Harness` 系统架构示意图 `Observation、Context、Memory、Actions` 等核心层级闭环 五、Harness Engineering 真正改变的是什么？
3.9K22编辑于 2026-03-30- 来自专栏开源物联网平台开发
Agent Harness 的解剖结构
Agent Harness 的解剖结构 原文标题: The Anatomy of an Agent Harness 作者: Vivek Trivedy 来源: LangChain Blog 原文链接 : https://blog.langchain.com/the-anatomy-of-an-agent-harness/ 翻译时间: 2026-03-21 摘要 (TL;DR) Agent = Model + Harness 代理（Agent）由两部分组成： 模型（Model）: 包含智能和推理能力 Harness（框架/装备）: 提供执行环境、工具集成和控制系统 引言 在构建 AI 代理系统时，很多人只关注模型本身的能力 本文深入探讨了 Agent Harness 的架构设计，帮助开发者理解如何构建可靠、可扩展的代理系统。 Harness 的核心组成部分 1. 持续测试和优化是成功的关键 进一步阅读 LangChain 官方文档 Agent 开发最佳实践 Harness Engineering 相关文章 注意：本文是基于原文核心概念的翻译和总结。
64910编辑于 2026-04-02 - 来自专栏DeepHub IMBA
Agent = Model + Harness：模型决定上限Harness 决定下限
Agent = Model + Harness 每一个 AI 编码 Agent 都是同样的两部分结构： Agent = Model + Harness 模型是认知基础：处理文本、生成 Token 的神经网络 Harness 是除此之外其他东西，可以把一个无状态的语言模型，变成一个能持续产出工作的编码 Agent。 编码 Agent Harness 的七个组件 Harness 不是一块单一的基础设施而是一层一层叠起来的能力栈。每个 AI 编码 Harness，不管包的是哪个模型，都会以某种形式提供下面这七层。 Harness 负责派生子 Agent —— 拥有独立上下文的独立模型实例 —— 在它们之间路由任务，并安排工作顺序。 Harness 是载体，治理是指令集。 把编码 Agent 的 Harness 理解成一个操作系统，而不是一个聊天界面，那些原本看起来像是小调整的配置决策，就会变成架构决策。
25710编辑于 2026-05-20 Harness Engineering：Agent工程新范式
二、Harness的五根支柱OpenAI把这套方法论拆成了五个可以直接落地的组件。结构化文档项目里维护一个docs目录，作为Agent的"单一事实来源"。系统架构图、执行计划、设计规格书都放在里面。 Agent动手写代码之前会先读这些文档来理解上下文。文档不是写给人看的，是给Agent看的。结构越清晰，Agent输出越准。 Copilot时代，AI帮你写得更快；Harness时代，AI替你写完整个模块，你负责验收。杠杆差了一个数量级。HashiCorp、Anthropic、Cursor都在2026年跟进这个方向。 四、Harness不是银弹它目前最适合的是边界清晰、规范明确的工程任务。API开发、数据处理管道、测试用例生成、文档维护，这些活儿的特点是输入输出可验证、有明确的通过标准、变更范围相对独立。 一个团队从传统模式切到Harness模式，前期需要一到两个月搭建和磨合。不是装个插件就能用，是一整套需要重新设计的工作流。
100编辑于 2026-06-08三个 Agent Harness 框架对比：OpenClaw、Hermes Agent、OpenHuman 到底差在哪？
AI Agent harness，但重点完全不同： •OpenClaw 解决的是入口与控制平面问题：怎么让 Agent 常驻在用户已有设备和聊天渠道里。 Hermes Agent：会自我改进的 Agent 运行时 Hermes Agent 的关键词是 self-improving。 harness”。 如果目标是构建一个能长期学习、搜索历史、生成技能、跨环境执行复杂任务的 Agent harness，优先看 Hermes Agent。 这三个项目放在一起看，刚好对应 Agent 产品化的三条路径： 1先把入口打通，让 Agent 能被随时唤起。 2再把经验沉淀下来，让 Agent 越用越强。
77921编辑于 2026-05-2605｜MCP 是什么：Agent Harness 如何接入外部工具
实际使用中，Tools最常见，因为它让Agent能采取行动。MCP在Harness里的位置MCP不是模型，也不是Agent本体。它是Harness的工具扩展层。 用户给任务后，模型判断需要外部信息，Harness把可用MCP工具展示给模型，模型选择调用，MCPServer执行并返回结果，结果再进入上下文。 这里的关键是：模型没有直接访问外部系统，访问发生在Harness和MCPServer的控制下。 这就是MCP的价值：把Agent从代码仓库带到真实工程上下文里。安全问题不能忽略MCP让Agent更强，也让风险变大。 协议只负责连接，安全要靠Harness、Server和企业策略共同完成。MCPServer设计建议第一，工具描述要清楚。模型是根据工具名称和描述选择工具的。
000编辑于 2026-06-08Multi-Agent系统Harness Engineering架构的思考与实践
模型的推理能力决定agent的上限，但只有在合适的harness中，这种能力才能被稳定地转化为可执行、可验证、可交付的任务完成能力。 harness这套agent工程应该怎么设计，首先还是需要基于agent的技术设计和实现架构，我们需要先从agent的设计模式入手，先看清楚单agent和多agent目前的技术发展，工程落地现状，各自能走多远 所我们可以看到强如opus4.6这样的模型，在使用multi-agent架构完成复杂任务上，也需要投入大量精力在Harness上。 考虑到MAS复杂度高于单agent，在MAS中生效的Harness工程架构应用范围可以覆盖单agent，所以后文提到的harness的架构设计都以MAS为基准进行设计知识供给层：不是仓库，是主动的信息生态定位 这正是三阶段演化能够成立的前提-不是因为模型越来越强就可以去掉Harness，而是因为Harness在，模型才可以将其决策推理应用到容错性更低，但价值更高的场景结语当下大模型和agent技术都发展飞快，
4.1K42编辑于 2026-03-13- 来自专栏DeepHub IMBA
Prompt、Context、Harness：AI Agent 工程的三层架构解析
或者说coding agent = AI model(s) + harness。模型是马，Harness 是所有其他部分，比如缰绳、马鞍、马蹄，甚至是路。 在cc中，AGENTS.md 和 CLAUDE.md 是最直接的方式：Harness 将这些 markdown 文件确定性地注入 Agent 的系统提示。 Agent 理解任务也拥有正确的信息，但仍然漂移、循环、做破坏性改动、静默失败或在长任务上质量衰减——Harness Engineering 出了问题。 Harness 层缺了 Context 层，则是一个受约束但无法获取所需信息的 Agent。缺哪个都不行。 如果正在用前沿模型而 Agent 质量仍然不稳定，模型几乎可以确定不是症结所在。Harness 才是。而 Harness 不用等下一个模型版本就可以修。
1.4K21编辑于 2026-04-15 - 来自专栏大前端修炼手册
从 OpenClaw 到 Android：Harness Engineering 是怎么让 Agent 变得可用的
说白了：Agent 出问题，80% 是脚手架的问题，不是模型的问题。这也是为什么 Harness Engineering 这个词会出现——专门描述"围绕模型的那层工程壳"。 三、Harness Engineering 的本质：在运行时建立边界 如果把 Agent 系统想象成一个工厂，模型是工人，Harness 是工厂的布局、流水线、操作规程和安全装置。 Harness Engineering 的核心转变是——把"说服"变成"约束"。 2025 年 Vercel 的 AI SDK 团队做过一个反直觉的实验：给 Agent 提供 20 个工具 vs. Android 上搭 Agent Harness，和服务端有什么不一样？ 最大的不同是资源约束。 Android 上的 Agent 还在早期，但 Harness Engineering 的方法论已经成熟了。这轮技术演进，最先吃到红利的，应该是那些把工程基础打好的人。
1K10编辑于 2026-04-02 长时 Agent 怎么交接班：读 Anthropic 这篇 harness 文章
长时Agent怎么交接班：读Anthropic这篇harness文章Anthropic工程团队最近发了一篇文章，题目叫《Effectiveharnessesforlong-runningagents》。 ，就把功能标成done这篇文章把问题放回到了harness。 所以文章的核心目标只有两个：先把初始环境搭成一个适合分轮推进的状态再让每一轮session都只做增量工作，并把状态交接清楚Anthropic的做法：拆成两个agent角色整个harness分成两个角色： 因为它说明文章想表达的不是“有了浏览器工具以后，长时Agent就稳了”，而是：如果你想让长时Agent跑得更稳，端到端测试必须进入harness。 所以这篇文章更适合被理解成：一套已经在工程里验证过、能明显提升长时Agent稳定性的harness设计。它还不是终局，但已经足够具体。
32900编辑于 2026-04-11- 来自专栏机器学习与统计学
2026 年，AI 编程 Agent 的真正分水岭——Harness 详解
现在社区里有一个越来越清晰的共识： Agent = Model + Harness Agent = Model + Harness 公式图解 Model 就是大模型本身——GPT、Claude、Gemini 《Harness Engineering for Coding Agent Users》，给了一个特别精辟的定义： Harness 由两部分组成：Guides（前馈控制） 和 Sensors（反馈控制 Claude Code 是一个优秀的 harness，特定任务的 Agent harness 在窄领域表现更好。Managed Agents 可以容纳任何一种。 所以，"harness 才是分水岭"这个说法对吗？ 我觉得对了一大半，但需要补充： 对的部分：在模型能力差距日益缩小的今天，harness 确实是决定 Agent 实际表现的最大变量。 所以更准确的说法是： 模型决定了 Agent 的能力上限，harness 决定了 Agent 能发挥出多少。
6.4K82编辑于 2026-04-13 - 来自专栏java金融
一篇讲透 Agent：Token、Skill、RAG、MCP、SDD、Harness
我的判断很直接： Agent 工程的核心，不是把模型换大，而是把 Token、Skill、RAG、MCP、SDD、Harness 这条链路搭稳。 这些词不是六个并列概念。 MCP 决定 Agent 怎么安全、标准地接触外部系统 SDD 决定 Agent 写代码之前有没有明确规格 Harness 决定这些能力能不能稳定跑成一个闭环 这篇文章就讲一个主问题： 为什么很多 Agent Harness：把模型包成一个可观测、可回滚、可审计的执行系统 最后一层是 Harness。 这个词中文很难一对一翻译，可以理解成 Agent 的执行框架、脚手架、运行时外壳。 如果说模型是发动机，Harness 就是车架、仪表盘、刹车、方向盘、安全带和维修接口。 没有 Harness，Agent 只是一轮轮调用模型。 有 Harness，Agent 才是一个工程系统。 Agent 工具越来越难维护，先看 MCP 或工具注册表。 Agent 写出来不是你要的，先看 SDD。 Agent 时好时坏、出错说不清，先看 Harness。
10710编辑于 2026-06-05 Agent 系列（五）：从 LLM 的角度聊 Prompt、Context 和 Harness
在一个 Agent 系统中，Context Engineering 还要决定当前任务目标是什么，历史执行到了哪一步，已经调用过哪些工具，工具返回了什么结果，哪些状态需要保留，哪些中间过程可以丢弃。 Harness Engineering 需要解决的问题。 Harness 让模型能力进入业务闭环 以 Agent 为例，一个 Agent 不能只靠 Prompt 和 Context，如果一个 Agent 要完成 “查询告警信息并生成处理建议” 这个任务，系统至少要处理这些问题 这也是为什么今天的 Agent 框架越来越强调 trace、checkpoint、human in the loop、guardrails、eval、tool approval 和 workflow。 三个阶段的关系的总结 4 月份在腾讯云社区 AI 公开课上，我做了一个名为《从 ReAct 到 Harness：谈谈 LLM Agent 的演进历程》的主题演讲，这里面我讲了三次范式迁移的分化过程（PPT
19710编辑于 2026-05-26Harness Engineering 被讲烂之后，Agent 工程真正难的是什么？
这层系统，现在常被叫作Harness。Harness要解决什么问题一个Agent连续跑几个小时以后，真正麻烦的地方，常常不是它能不能继续往下跑，而是它是否还知道自己在做什么。它怎么知道刚才做到哪一步？ Anthropic：把Harness拆成一套Agent操作系统在这三家里，Anthropic是把Harness拆得最细的一家。 这说明一件事：长程Agent的问题，很大一部分是交接问题。Harness要让下一轮Agent不必靠猜。再往前一步，是上下文怎么进入Agent。 所以Harness不只是“给Agent接工具”。更重要的是：把工具设计成Agent能理解、能选择、能验证的行动接口。另一个问题是自评。 这让评估也成了Harness的一部分。Agent的质量不能只看最终回答，还要看它在环境中的行动和结果。
33410编辑于 2026-05-20- 来自专栏架构之巅
Harness架构下的Agent研发：从SDK到工程化实践
然而，当开发者试图将这些“天才大脑”转化为能独立完成代码编写、数据分析、信息整合等复杂任务的“智能体”（Agent）时，却常常感到力不从心。 Agent SDK：开箱即用的智能体构建利器理解了Harness的理念后，如何快速将其付诸实践？ Claude公司推出的 Agent SDK,他实现了与claude code一样的能构建自主读取文件、运行命令、搜索网页、编辑代码等的 AI 智能体，正是这样一套践行Harness理念的通用开发工具包 革命性的开发体验使用Agent SDK，构建一个智能体变得异常简洁。 应用前景与当前挑战基于Harness架构和Agent SDK，可以快速构建出多种实用的智能体应用：自动化的代码助手：不仅能建议代码，更能直接分析代码库、定位错误、编写测试并执行修复，形成“分析-修改-验证
1.1K20编辑于 2026-04-07 我用 PAICodex 理解 Harness Engineering：Agent 工作环境到底怎么搭
这就是我现在理解的Harness：它不像一套框架名词，也不像几个Agent拼起来的流程。它更像一个工作场。 好的入口更像一张简短地图：先告诉Agent现在在哪，去哪找资料，哪些地方不能乱碰。入口太短，Agent会猜。入口太长，它会淹没。Harness的难点就在这个尺度上。 这几轮我和Agent之间的反馈过程，本身就是一种直观的Harness，甚至比引用别人的Harness文章更能说明它是什么。这也侧面说明一件事：如果没有外部反馈，Agent很容易停在第一版。 工具可以换，只要这些关系还在，Agent就有工作场。工作场的核心是沉淀如果只让我用一句话说Harness的精髓，我会说：把每一次对Agent的临时提醒，尽量沉淀成下一次默认生效的环境。 所以我现在不太愿意把Harness讲成“模型之外的工程系统”这么宽泛的话。那句话没错，但容易变成概念。对我来说，它更具体：Harness是一个让Agent不必每次从零开始，也不能随便宣布完成的工作场。
21110编辑于 2026-05-20Agent 搜索里，Harness 比检索方法更重要
这个背景也解释了为什么这篇论文没有只停留在检索算法对比上，而是把重点放在了Harness、工具返回方式，以及端到端Agent表现。 他们比较了两种Harness：自定义Harness：Chronos，作者团队自建的长对话记忆Agent运行环境；AI厂商原生CLIHarness：ClaudeCode、Codex、GeminiCLI。 除了比较不同Harness，这篇论文还特别看了一个细节：搜索结果是怎么返回给Agent的。 另外，Harness本身也要被认真评估。很多时候，我们说一个Agent“检索能力不行”，不一定是模型不行，也不一定是检索方法不行，可能是Harness没有把搜索工具设计好。 Agent搜索能力不是一个单点能力，而是由模型、检索方法、工具接口和Harness一起组成的。一句话总结这篇论文表面上是在比较grep和向量检索，但它真正讨论的是Agent搜索的系统设计问题。
18810编辑于 2026-05-26- 来自专栏MixLab科技+设计实验室
Harness：让Agent不再犯重复错，但这还不够
Harness（驾驭工程，2026-02-）：关注 Agent（智能体）运行环境的可靠性。在模型外围修环境。 Intent（意图工程，2026+）：关注人机接口处的意图对齐。 你搭一个 harness，让 Agent 不再犯重复错误：OpenAI 在今年2月发布的百万行代码实验报告已经把最佳实践开源。也就意味着，任何一个工程团队都能复刻。 重叠区是"用 harness 治理 agent 行为 + 用交互层收集意图反馈"的协同。 七、启发 给工程师 不要再沉迷于我会写 prompt。 Prompt 是 5 年前的特长，今天是基本功。 给投资人 未来的 AI 应用公司估值，应该看两个并列指标： 驾驭工程密度（Harness Density）：单位用户行为里，有多少比例是产品主动用 harness 帮你"管住 Agent"了。 Life-Harness 论文显示 126 套组合中 116 套因 harness 优化提升，平均 +88.5%。
1200编辑于 2026-06-08 agents-hive 开源了：一个面向生产的Harness Agent 工程
agents-hive 正式开源啦商业级 Agent 工程化管理系统 我们理解的 Agent Harness 在 agents-hive 的设计里，Harness 从来不是"让 Agent 跑起来的东西 Harness 是 Agent 的完整生命周期管理系统。 它是 Agent 的运行容器、安全边界、观测仪表盘、调试工作台和迭代引擎。 Harness沙箱隔离│权限控制│成本控制│超时熔断│审计日志Agent RuntimeReAct循环│工具调度│上下文管理│状态持久化│任务恢复 agents-hive 的四大核心工程能力 全链路无死角执行回放 这是我们认为 Harness 最基础也最重要的能力。 生产级安全与约束体系 安全是生产级 Harness 的底线。
24810编辑于 2026-05-18- 来自专栏运维有术
6.7% 到 68.3%：Harness Engineering 六大支柱如何重塑 AI Agent 开发
Agent = Model + Harness：一个把系统切开的公式图 2：Agent = Model + Harness 三层嵌套架构LangChain 把这件事用一句话说透了：Agent = Model 模型本身只是能力的来源，只有通过 Harness 把状态、工具、反馈和约束串起来，它才真正变成一个 Agent。 他们的对比数据很有说服力：配置耗时花费效果Solo Harness（单 Agent + 最少工具）20 分钟$9跑不起来的半成品Full Harness（三 Agent + 完整工具链）6 小时$200 Agent 布置任务外包确定性任务挑出 Agent 几乎一定能做好的任务后台跑工程化 Harness每当 Agent 犯错，就工程化一个解决方案让它永远不再犯始终有 Agent 在跑目标是 10-20% Harness）：https://blog.langchain.com/the-anatomy-of-an-agent-harness/如果你的团队也在做 AI Agent 开发，转发给同事看看——说不定你们踩的坑
97421编辑于 2026-04-27
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号